As computer processors become increasingly powerful, the speed of access to data becomes a limiting factor in the operation of a computer system. In a concurrent trend, computing in general is moving away from a model of independent, standalone machines, toward a networked environment, in which data and other resources are distributed across different machines and locations, connected by networks. Accessing data across a network introduces further latency into an operation that is already slow. It is therefore desirable that the speed of access to data is increased, both locally on a given machine and—even more so—remotely from a network file server.
At the same time, the goal of increased throughput (and/or reduced latency) should be achieved without compromising the stability and reliability of the overall computer system. In one aspect, this means that the user or application wishing to manipulate given data would like to have confidence that the operation has been carried out successfully, or at least would like to be informed if a failure has occurred. The validation of data manipulation operations, such as WRITE operations, imposes further constraints and has a tendency to increase latency or delay.
In the context of access to data over a network, a number of protocols have been developed which interact with the underlying file systems of a computer and act to make the data stored therein available to other (client) computer systems elsewhere in the network. One prominent example of such a protocol is the Network File System (NFS); however, many other such file sharing applications exist—such as the Andrew File System (AFS) and File Transfer Protocol (FTP).
Typically, such protocols operate according to a “client/server” model. A server program (for example, an NFS server) runs on the machine which is responsible for the relevant data storage device. The data storage is managed by file system layer software, which executes all operations that manipulate the data and also typically maintains records of the “attributes” of the data. These attributes comprise metadata such as the date and time of creation, or modification, of a file; a pointer or index to the physical location on disk where the file is stored; and permission-metadata for access-control.
When a remote client machine wishes to access the data, client software on the client machine communicates (via the network) with the server/host. The server, in turn, maps and translates requests from the client into instructions to be executed by the file system layer. Here the “file system layer” refers to the physical file system. Well known example file systems include the Unix File System (UFS) and VERITAS File System (VxFS; also known as JFS or OJFS).
In many cases, the whole process is completely transparent to the application software on the client machine. That is, the application software simply requests access to a given file, without regard to whether it is stored locally at the client machine, or remotely on a network server. The NFS client software (for example) detects requests that relate to remote files and forwards them to the NFS server software on the relevant host machine.
Many file server operations are carried out in a “synchronous” fashion, with respect to the client. This means that the server function does not return (that is, respond) to the client until all the underlying file system operations have been fully completed. In other words, the client process “blocks” until the server returns. This provides reliability at the cost of increased delay—the client understands that it must not assume that the requested data operation has been executed until it receives the confirmation from the server; therefore, it should wait for the confirmation before proceeding. If, for example, the server crashes before the data operation has been completed, then the client is alerted to the fact that its request may not have completed, because the server has failed to respond normally. Typically a client will re-try its request in such circumstances.